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(57) Abstract ; 

A method and apparatus for con- 
ducting electronic transactions and au- 
diting electronic transaction documents 
in an online transaction system allow 
users to accept or reject received elec- 
tronic transaction documents, wherein 
the acceptance is non-repUdiable and is 
based on the content and terms of the re- 
ceived electronic transaction document 
Transactions may be conducted between 
two or more parties, and '.may include 
non-party participants. Electronic trans- — 
i action documents may be stored and ay-^ 
dited by vaHdating digital sj^natures^and. .. 
verifying ^HaCuVc^ : 
tronic transaction tid^niems J h^ve, ndt 1 ; 
been compromised.'* ^ 
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MECHANISM FOR MULTIPLE PARTY NOTARIZATION OF 
ELECTRONIC TRANSACTIONS 

This application claims priority ofU. S . provisional patent application Serial 
5 Number 60/ 1 05,778, filed October 27, 1 998, which is co-pending and incorporated 
by reference herein. 

FIELD OF THE INVENTION 
The invention relates to computer systems used for business transactions, 
10 and more particularly to client-server software systems which exchange business 
transaction data between participants to business transactions. 

BACKGROUND OF THE INVENTION 
When companies engage in commerce activities using computers, software 
15 systems are employed that handle all manner of business management and 
communications. The operation of these systems results in the execution of business 
transactions. Business management systems include accounting, order processing, 
job tracking, billing and resource planning. Business communications systems include 
electronic mail (e-mail) for l fekbhahging messages between people, electronic data 
20 v interchange (EDI) for Sehifihg^ and receiving structured messages for purchasing, 
inventory control and financial payments between organizations. In recent years 
_ t Wiprld Wide Web (referred!, to herein as the "Web"^ technology has allowed : ; 
companies to provide interfaces to business systems^Wprkfl and coUaboration 
ttaougfr^ as Microsoft Internet Explorer, Netscape ; }1 

25 Navigator and Netscape Communicator. All of these systems c$n allow some foim 
of commercially significant business transaction. Companies need to track, manage, 
verify, audit and share records of these business transactions. 

Electronic commerce systems have traditionally been based on EDI 
technologies, where companies exchange highly structured messages that conform 
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., to ANSI or ISO. standards for describing a myriad of prodGct ordering, tracking and 
payments.^ 

. ,or requ,s,tion,system and: sent, to a communication ^sysfein Wtransmks the 
message .oyer a computer network to the destination ^mpany^When an EDI 
.message is delivered from one '^m^^O^^^^^^^^ 
, ,cpnve.rs,on,syste m :that will convert the standardized EDI mgssage data^rmat into 
the data fbrmat-requixed by the receiving compos order processing system. 

Many electronic commerce systems incorporate cWogrlphic Actions 
a, the .level of the communications subsystem: F6r example, a communications 
subsystem xwhich might be an e-mail system, for example), might automatically add 
t - a d,g,, a | s.gnature to each message from Qne p ^ y ^ ^ 

: the reap^communicationssubsystem to Verify the authenticity of the message 
Bu, these functions take place atthe lev^l of the con^unications^subsystem, not at 
the level of the order processing or requisition system. They are frequently 
transparent to the order processing or requisition system, and to the users The 
d,g,t al : s.g„ature appended to the message ^might be that of the company instead of 

.the ,nd,vidual who placed or acknowledged an order, and no auditable record is kept 
, -th^order processing^ requisition system of who sighed ea'ch message sent or 
- rec^yeAManv;^ feuirn an acknowledgment to a 

message sender that a. messag e was received: But again, such acknowledgments 

Pften.occur automatically at the level of the communication sub^exh arid are often 

.(such. as.tepnsfand conditions^ a transaction): SoHe eiedfb^c^aiier^ systems 
Ldo .prpy.de. electronic acknowledgmerits ^rigiriatihg at the i^eVoT the order 
processingorrequisition,butthe S eare^ 

the communication subsystem, with all its attendant problems), and certainly are not 
intended to evidence legally binding acceptance of the message content 
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, w New r |g^ : p£ejectt^^ 

These; ^t^^oy^i^py users to access an oidine catalog. GiistomSrs tan browse 
, thp^atajog^ 

When a prpduct^s ordered, many of these^servers wiliprint an arder tracking number 
: 5 ; f c ? e 5? ?0 ^ at the wstomer has some reference: tb f the ordfef in case the 

customer has ^ prpblem or question regarding the delivery of thfeprbdiitt or service 
t ! iat ™^ PPf" P hase 4 Some systems will send an e-maiLmessa£fe to the customer, and 
the ^-mail niessage will contain the order number in it. 
: ^ A iiurpber of financial services companies* particularly bank^ ahd stock 

10 brokers, use similar technology ,to enable customers to access bank and stock 
accounts and to make monetary transfers, bill payments or perform stock trades over 
the Web. Like electronic catalog commerce systems, these financial services systems 
might print an order tracking number to the screen or may send an e-mail message 
containing .the order, tracking, number. Some providers also 1 send a printed paper 
1 5 receipt to the customer using regular postal -service. , . : 

^nother type of business transaction involves the acceptance 6f terms and 
conditions and poijtracts online. .Typicattyr -an - onlihe^ervicfe that is Offered over a 
Web browser or with ^ 

customized software on the client computer that ^mtnunicates to a server at the 
20 bank oyer a cp^iput^r network) prints % screen of contractual terms regarding the 
u$e of the seryi^e, The customer is a$ked to click a button that 'Concerns the 
r - - ?V St ?™ e f S < $?^^i?^?% t ?^ ^ conditions. ©ncea custditter adapts these 
terms,, the service 
, of th^^servte^end an 

25 „ e-mail message-that recapitulates the terms and conditions that wdte aecepted by the 
customer. Howeyer^the majority of these services provide^b^Olfitely ho record to 
the customer of the terms and conditions, and likewise provide very little in the way 
of proof that the customer actually accepted these terms. 1 " ' : 
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. ... ■ A similar sfoiatioriWthe terms intenodB^rfttfe services exists in 
, the acceptance of software -license agreements! ^ic^if a software' program 
, presents a license agreement to^the eastorife^en^so^%i,is^ed or used 
for the first time, men the customer clicks a button to signify agreement to these 
• t^rns, the.sofrwanrbecomes operational* dually ^ 
,,, customer to=save these terms and conditions for later reviewer for approval by an 
attorney prior to signifying agreement. ' v r - . T 

. .Many companies use collaboration and groupware tools such as Lotus 
Notesor Web-based systemsto share information and business documents withinthe 
company and sometimes with business partners or customers. These systems 
sometimes provide a form of centralized tracking and aud'iting of the actions that 
people have taken in the system. Usually this consists of log files which are text files 
that contain an ever growing list of actions that the software performed, usually in 
human-readable format; Another mechanism is provided by such systems allows 
activity to be recorded in an application-specific database. 

When companies use electronic mail (e-mail) to exchange messages and 
- files with employees, customers of partners, there is often no way to verify that the 
message was received and read by the intended recipient. Some systems ask for the 
receiver to.send an e-mail that confirms the receipt of the message: Other systems 
,(seeTumbleweedU,S^ 

a database and. Web based system to track when the milage was recced. The 
message to be sent is stored in a database oii aserver: An e-mail message is sent to 
^Pti^he^ to ^ a 

\~, ;Web, >site -to ■ retrieve •=the i hiesssigeT 'The Web m&^M^t''& m ^g e ^ 

server, the underlying database makes a record that the message wis viewed. With 
.these systems the sender can use a Web-based interface to see if and when the user 

has read.the message. 7 
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> ^ ^ ^m^fla^ & ? ate ^ No. 5,739,5 Unincorporated by reference herein), 

, r , a ?^_anisig ^^g^B^^^hereby a consumer purchase made at #cash register with 
a ^41$ ^^95 jjg^^pfg, c^n generate a digits receipt that is:e-inail^d to the e-mail 
, , , a( ^ress of the* purchaser. Jhe intent of ^h^ '512 system is to provide the purchaser 
5 , ^th an ^l^tronic record of the purchase, Sucji a record xx)uld pre^ 

: n }*? tl !f PWcha^er tp be entered intp anaccpunting or, expense tracking ^stem to 
track his or her purchases for reimbursement byi an employer. \ \q ■•■ ' ^ 

Thus, therp is a need, for an online ^transaction system that allows users to 
conduct online transactions in a manner jthat evidences a participant's acceptance of 
10 the transaction. () 



SUMMARY OF THE INVENTION 
According to the invention, roughly stated, an online transaction system 
allows users to accept or reject received electronic transaction documents, wherein 
15 the acceptance is non-repudiable and is based on the content and terms of the 
received electronic transaction document. - t : : J . 

In one aspect, the present invention provides a method and apparatus for 
, conducting electronic tran^ctipns between at least first and second parties in which 
the first p^rty sends to the second , party an, electronic v transaction document 
2 i? , ev i^ncmg ^ment,wMc^is : p t>y the first party; the ; second party may 

accept the content of tjbie electronic; transaction documented send a response to the 
first party that is non-repudiable ^ . , : , ^ d o ^ , 

. .^,^^^.f^^,*«^«^»^?^9^ prQ^des aa^hod aiia apparatus 

{ or , ^"^^g^ec^prap ,tr^<^on^J^et«f^.at T J^J^^ai^ second parties in 
first party obtains^the digital signalure.of a flOB-paity participant and 
includes this in an electronic; transaction document evidencing content that is non- 
repudiable by the first party; the first party transmits the electronic document to a 
second party; the second party may accept the content of the electronic transaction 
document and send a response to the first party that is non-repudiable by the second 
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, party. The second party may also obtain the digitai^t&e of another non-party 
participant and include this in the non-repudiabie resp'onSet 5 ^' 1 : ' ' 

In yet another aspect the' present InvWtidfc proves a method and 
apparatus for auditing electronic -transaction tfScumenS'% "Vanning digital 
< .signatures and verifyirigttat the content of stored electronic transaction documents 
has not been compromised. '* ; 

-Otherfeatures-and benefits of the present invention Will be apparent from 
the detailed description of the invention when considered with the accompanying 
drawings'. . ;\ . . 

BRIEF DESCRIPTION OF THE DRAWINGS 
The present invention will be described with respect to particular 
embodiments thereof, and reference will be made to the drawings in which: 

Fig, 1 illustratessymbohcalrythearchhectureofthewhichimybeusedfor 
implementing the present invention; ' 

1 Fig-. 2 illustr ates symbolically the electronic transaction document; 
Figure 3 is a flowchart showing the steps which are performed to conduct 
-an online transaction-"- - r - '>■'■ "* "■ v -" r - 

' i: ° ; " iFig 4 is>a fl ^ ch ^ sh0 ^ n g ; the ^ 

..ejeetfonic traos&riori 'document;- "' : - : ' •'» f 'im3«-*r t -i,*-- . !,.u • V 

- ; v;^ Fig;: SaMs^ flowchart ^owmg-the-^wn^ffiie performed to gather 
■■ rouMple.digital sigriatureslmpatallel; i ' ' T -■" ^ :l ' f ' r ;r • 4 

Fig. 5b is ^fi^wc^^owmg^e-'^pk wftcli ^perf^rnied to gather 

;;mur:ipJe$gitafcsignatu^ *3-.5it,-.H 

a transaction requiring me digital signature of a' single non-party participant; 

:■ Fig. 6b is a flow diagram showing the logical sequence of steps executed 
by the present invention to conduct a transaction requiring the digital signatures of 
multiple non-party participants; 
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I ^ ig ^j?^3^^ ti ?P 9 f a interface screen used tcf view arid accept 
electronic transa^io^^ocuments; r ,. r > f ^ } ; ^. ; i: , : ;r : ^ 

f t f?r-W MV s ^ on : of > usgr .interface screen used to display and 

manipulate received electronic documents; ? * .. • 

Fig. 7 c is an illustration of a user interface screen showing a list of related 
documents; , v , ^ ~„ > t 

,. Fig 7d is, flowchart showing the steps, which are. performed to audit 
electronic transaction documents; and , ■■■..>. ■ ■ 

Fig. 8 is a schematic in block diagram form showing, a high level 
representation of a computer system used to implement the present invention. 

DETAILED DESCRIPTION 
A transaction is a communicative action or activity involving two or more 
parties that reciprocally affect or influence each other. Important examples of 
transactions include promises and agreements which describe current or future 
activity or inactivity, as well as activities that have already; taken place. As used 
herein, the term "transaction" includes sub-transactions, which are transactions that 
are themselves parts of larger transactions. For example, a transaction that is an 
agreement includes a transaction in which one party makes a promise to a second 
parry, and another transaction in which the second party makes a promise to the first 
party. As another example,, an agreement -among thKse. parties; may include one 
transaction in which party A makes prqn-dses tp pai^ B^iand a secohd^ransaction 
^$P?fyM p^mj^t k o,jpa^^ l ajd J ,siorp8. { .i r ;>: . T <vl 

Entities participating ; jn transactions..nTay, iri^ude: party non-party 
participants. JTartjeff' are {be primaiy. f^dp^^-t^ateactioii, and indicate 
consent to be bound tp the terms of the transaction by;attaching< signatures to the 
document evidencing the transaction. If the transaction includes a promise, for 
example, flie party participants in the transaction include the promisor and the 
promisee. Non-party participants include entities such as notaries, auditors, or other 



•V" 




WO 00/25245 



BNSDOCID: <WO__0025245A1_I_> 



o o o o 

W ° 00/25245 ~ f - PCT/IUsi/24570 

-8- 

^ - io Signatories required to serve to validate the transactfdh/grant permission to a party 
-. v; Pupate in A transaption; or otherwise •saVeW^^^ess'tb the^raiisactkm. 
. ; ^ The signature of a non-party -participant . seiVes to acknowledge' the transaction 
„ without incurring an obligation or indicating acceptance of Serins by the rton-party 
5 . . participant. „... / . : .- -,i .<-■■'. t j '.fcj ' 

>r- t: •» :• ; A €<fflft can^be conditional and/or one-sided. A purchase 3 order, for 
- example,, can evidence a promise on the part of the purchaser to pay a certain 

amount of money if the vendor delivers the requested product or service. A credit 
, card draft, for example, can evidence a promise on the part of the purchaser to pay 
10 money in accordance with a cardmember agreement; 1A credit card draft might also 

evidence activity that has already taken place, for example delivery of purchased 
... goods from the vendor to the purchaser. • 

........ An "Agreement" includes reciprocal promises by or among at least two 

parties. , \ ,. 

15 , Atransactionaocumentdescribesthe essence of a transaction. Transaction 

v . documents may, include offer letters, purchase orders, acceptance letters, receipts, 
sales slips, etc. A transaction .document is' signed by or otherwise evidently 
^associated whh -the iP arty or parties incurring an obligation uriSer that transaction 
r document, and may, also bear the signatures of nonparty participants: Transaction 
documents establish that the transaction ; actually occulted, so W 
^diatS,* transaction. documents identify the^terms of the transaction, the 
re^ns^^espfthRTe^e^ve-paities to the transaction, iny products, 'services or 

;c v^,^e.,ti;a^ctiqn,i ;: sighify^gd their: ^c^eptance^-6^e ?n trans^^^ - Transaction 
docu n}ents.usually.pi-oyide some safeguard -that makes' evident arty alteration to the 
..transaction document after a party has placed his or her non-r^iable mark on we 
transaction document. For example, carbon copies of transaction documents may 
be used to verify original transaction documents. As another example/ signatures 
may be certified 
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v?*! e vJ^S'ftfr'trust Jn transactions is the- simultaneous presence of both 
. parties t^.%.^^ej^O:wtness-thetraiisa^OT document's content and signing. 
} n the on-line wpijdj siph simultaneous presehceiis neither possible nor desirable. 
Instead, electronic transaction documents" provide proof that copies" held by both 
5 parties are identical with respect to terms and signatures. A transaction document 
,m sent from a first party to a second party S often- triggers ^subsequent transaction 
document to be sent from the second party to the first party in "response to the 
preceding transaction document. ' • : : 

As Hsqd t herein, a, given -action or event occurs "iii resp6nse L to" to a 
1 0 preceding a^ion pr event i£the preceding action Or event influenced the given action 
or event. If there is <an intervening action, .event or time period, the given action or 
event can still be "in response to" the preceding action or event. If the intervening 
action, event or time period combines more than one ! actioh or event, the subsequent 
action or event is considered "responsive" to each of the action or event inputs. If 
the given action or event is the same as the preceding action or event, this is merely 
a degenerate case in which the given action or- event is still considered to be "in 
response" to the preceding action or event. \ . c.i ; - : 

, >. term "electronic .transaction document" as used herein refers to an 
electronic document that, establishes an, online transaction between two or more 
participants. An. eleptrpnic transactioa document may contaurdata describing the 
transaction, digital, signatures (certificates) identifying the parties to the transaction, 
, ^ d ?/ tam P^ r "W°f se^.(e ; g v checksuni/on|an em^^ codmg ofthe contents of 

e^^W^Sn^^H^^r-Pft^ Wfcraswtion-ihay af^ea^^el^c^hi^ti^nsaction 
document as required in ; various applications or legal juriidktionsV'Fbr example, 
electronic transaction.documents typically include the date'oFissue or signing. A 
single electronic transaction document, bearing the digital signatures' of all of the 
parties may be used to establish the transaction: In the alternative, a plurality of 
transaction documents considered together may establish the transaction, with each 
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! ; /i - - electronic transaction document establishing separate aspects of the transaction. 
V Electronic transaction documents may be transniitte^ o^ePctimmunication networks 
• such^ais the-Web. r.*.*r> " e .v ;■;;..-.: -> s. •• , vA b.-/'^.-.."." ;> =- 6 : v^-.c ■•» 

:•- Asusedhereinrthe entity that issues'an eledronic transaction document is 

■ : 5 referred : to. as the 'Jissuer'f and the entity that receives the ^e^tfc to^ansaction 
' document is issued is referred to as [the "recipient." Generaiiy/issuers and recipients 
are signatories who are parties to the transaction and are required to place then- 
digital signatures on the electronic transaction documents. However, recipients may 
also include third party signatories, such as notaries or auditors, who are participants 
1.0 i but not parties to the transaction. ; - • r --- 

directing attention to Fig. 1 , the Transaction Document SystemTO enables 
electronic business transactions to be conducted across the World Wide Web 20 or 
other communication systems that support remotely located computer systems. The 

- communication subsystem can include a web interface system, an e-mail system, 
15 (with or without its own cryptographic features), an EDI system, a private direct 

r ;- communication link, or any other communication subsystem, either separate from or 
bufltmtotheTransactionDocunient'System id! TheTransactioriDocument System 
: 10 comprises. a J Transaction Document Server ' 3& implemented on an issuer's 
*-* computer system,' and a -Transaction 1 Document Client 70 implemented on a 
20 recipient's computer system. ; Iii f general, the business logij of a transaction is 

- . implementedin the workflow system 90 and the Transaction Document Server 30 

executes protocols for e&aiifirig signatures. Depeiidiiig- on the appHcation of the 

"* - L !; *<*&a*»^I^^ 4amay ^ustoml^i to accommodate 

;; >:< h>;: variouslworicflowJsysteinsV'i 1 f -' ( ?M : ' ) i-.au?. r,:r ic- :n:..>\^ 

25, v i ■» iT^iThejJPraiisactibttvDbcument 'Server 30" is limjiemente^on the issuer's 
■ : , computensysteni and is used by the issuer to produce and publish ah electronic 
'■■ tran saction document bearing the issuer's digital signature! The Transaction 
Document Server 30 includes a set of computer instructions that, when executed by 
a computer system, executes the method of the present invention. The Transaction 
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- ... v . D ? t ?f nert Sec^fS 3&m.a;y be implemented, as a service plug-in to a regular web 
. , : se ^ eT ^ ^^ e f^c^P T ^M n &> fonexampie, the 1 serviet API, ISAPI <if NSAPI. 
Protocols are executed for gathering signatures when the Transaction Document 
; . . ^T^f^JSPT^ Request from a commerce server or dther workflow system 90 
; . - J , .. v to t gene r ^ te ^ electronic transaction document for. a Web^ased transaction; or from 
» a fil / W er ; RSe ne rate an electronic transaction document to be transmitted with 
afile. r> i . . ... . ,. ; , ... . 5 . _ . ,. . 

. , , X he Transaction Document Client 70 is implemented on the recipient's 
computer systeni and is .usod by redpients .tOKreeeive and sign-their copies of an 
1 0 electronic transaction document. The Transaction Document Client 70 includes a 
set of computer instmcrtionsthat,;wheniexecuted by a computer system, executes the 
; method of the present invention. The Transaction Document Client 70 may be 
implemented as an extension to a file transfer client (such as the FHeDri ve client 
available from Differential, Inp., Cupertino, CA), or for web-based transactions, as 
15.. a browser plug-in or Java applet. In the latter two cases, the Transaction Document 
Client 70 installs itself on the recipient's system such that it is invoked seamlessly 
when an electronic transaction document is received. .,; ■< '- . 

■ <" Com P ut ? F m ^^ on s" for 7 performing various tasks as described herein 
can be stored, on a non-yplatil© computer, storage medium (e.g. hard 1 drive, floppy 
disk, optical disk, or the like),, or in a volatile computer storage medium,- such as a 
computer's main memory or cache memory, or any combination or storage media, 
e '!l?. e r * n ,?ne location or spread oyer anunjber of locations. :.. .r--.r .-o : ; x x:> 
;;: u .-> /? e r^^^.^ r 3 nsa ? tion P°W men t Serycr SO ant Client 70 include an 
Application Specific Interface (API) 40. Th&^I-^/aflowsi^ct^nsaction 
. Document Server 30 and^or Client 70„to . commynieate. with outside application 
programs such as workflow systems 90. ; The ABI 40 provides'connectmty to other 
software systems that utilize the Transaction Document System 10. The API 40 
may contain three or more levels. These include a high level API, a low level API, 
and a workflow API. The high level API has a niinimal set of calls, may include UI 
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? components, and perfonns^ost of Hs functions Mugti^s tb the low level API. 
.^p^.ley/d.mm^^platforin independent; f ; and- borates anextensive set 
, of Unctions, As the low lc«dis'ino^W^M%hte &PI, thelowlevel API 
does not require a UI. The workflow API provides cormerfivnSr io ^'workflow 90, 
which mayvbe .an, external rcoWrcVfcfrv* -or 'corp6» -workflow system 
Addition^ 

API's which may be used by different systems such as B SAFE or MSCryptoAPI. 
The crypto API provides the low level API with platform independence. 

: The/Transaction Document Server 30 and Ghent 70 may also provide a 
web-browser user interface^) 42-for recipient that allows them to sign and 
validate electronic transaction documents as well as track transmission and provide 
auditin g! fbnctions. TheUI 42 is described in detail below. 

A validator module 44 may be incorporated into Transaction Document 
Server 30 and Client 70. a The validator module 44 checks the validity of an 
electronic transaction document. The validator module 44 is called whenever an 
electronic transaction document is received; or it may be called as needed for 
auditing purposes. The, validator module 44 validates each signature (certificate) on 
the electronic transaction document by verifylhg the certificate with the appropriate 
certificate authority (CA), e.g. Verisign. It also verifies that the contents of the 
electronic., transaction document have not beeH altered, by validating the 
; ^per.proof seal (i.e. the digital signature, th^cnecksum on*he encrypted contents 
Mm,^^trmtsac&m dde>iment)V^ depends on the 

^gni*^^ the^afticular^^^ keeps 

karate f^^f^^m^M^of^^m^ in^s^ ^Widator 
-module*, would validate each section ^eparatel^ Conversely, PKf3s#7 does not 
keep ^separate checksum in the clear; : the validator module 44 has to reconstruct it 
from the message itself. ■ • - 

The Transaction Document Server 30 may also include a server 
administration module 46 provides screens that allow the administrative users to 
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perform the £ mQ^^grt^t tasks- of setting.up, configuring and maintaining the 
Transaction i J^o^nent^Server 30. ThevadmMstr&tiptt<iftbdul6'-4fe- pWvides a user 
.. interface that ^ 

functions include: ..>%.... ,.• .....r 1 1" . *, ! :;. . ■ : ~ 
r 5 . ,° • •• s ^ t S 1 9-, l ?P ths ; server port -and coimectioii&panuneters: "•' 4 '" : : 

, ' . ^ tt ! n g up the email configuration fotfsehding messages and electronic 

. .. transaction documents etc. to clients.: - >.• :i *■ vt . r r! ?■ >-'•- 

5e^ing up initial parameters for encryption and the certificate to be used 
for signing electronic transaction documents and messages. 
10 - * ,-. Setting up the logging andv auditing , parameters for keeping track of all 
transactions: and error messages. . , vs ' 

• Database , maintenance procedures forj validity checking to see if any 
electronic transaction documents are* corrupted or transactions were 
tampered with. Validation reports can be produced. 

15 ' Selection of document formats from a set of available templates/Templates 

can be created/edited with a separate template editor using XML tags. 

* Cre^t^ and modify user accounts for access to these' administra^on pages 
, and aUocate.appropriate.levels of -autborization-.; i/.i ^ ' •:> 



?° . . . . . The -P ata , I>efinjtion ( ..50 is utilized by. "both -the Trahsactiari Document 
Server 30 and Client 70. The Data Pef^tion,50cc^tamsi!ibraries'that describe me 
various represe^^o^pf.electronic transaction documents; and tfarisforinations 

optional dat^^andprotppQ 
25 ,o documents . ;t , -P»e t .. . transformation • . methods, -define thex/mappm'g between 
representations as required for compliance with different standi 
system. Representations include Internal, Database and Published. 

The Data Definition 50 also includes a worldwide unique ID for each 
individual electronic transaction document, consisting of a combination of the 
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Issuer-s Certificate Authority's ID, the Issue* Cer^b, and a tracking number 
generated by the Issuer. The Data Definition "50 maf^ mc l ude in dexing nhooks „ 
for associating electronic transaction documents ^ih a' Transaction ID and "for 
associating them with one another in sequential relationship (i e: a chain of 
transaction documents) and replacement. , . 

The Internal Representation 52 provides the classes for the various types 
of electronic transaction documents implemented on a Transaction Document Server 
30 or Transaction Document Client 70. A generic transaction document class may 
be .mplemented on the Server 30 and Client 70, asweil as other classes with 
spec.al.zed data and workflow behavior. Examples of the classes defined in the 
Internal Representation 52 are provided belbw. ? 

The following examples of class definitions included in the Internal 
Represemat^arepro^^ 

that the following classes arenot to be considered the entire set of ciass. definitions 
comamed in the Internal Representation 52. It is also to,be understood that changes 
to the content and format of the class definitions contained in the Internal 
Representation 52 may be made without departing from the spirit of the invention 



<!-- Document Type Definition or E^^onid^Trarisact Document 

<! class Digital Receipt7--> " " * ;„ 1 ' 

<?xml version = "1 . 0**?> -,\ - .\ 



<!DOCTYPE digitalreceipt [ ~' " 

<!- List of the ELEMENTJ^^^^a:^^ ^g^L* 

_ :> NOTE that the digital- signals) :■«* ap P endedJio;th^ Receipt 

are Venerated"™ 0 * deSCribed ^fi^tlon 'because they 

- from a document digest that encompasses the XML document . 



< I AA 

> 



<! ELEMENT receipt 

(issuer, 
recipients, 
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datejlssued, f ; * ; , 

transacti9n, r ; ■ *- ( v 

5 ' other info - . • A • . . . 

■% — . c; : .)>:: dh~ :< ■ - - ^ - '"-w^ ^- ' ' '"" r ' '* 

i ; • < • ELEMENT issuer ( signatory j> v? , " t/ " fwt ' : ' : '' " ri ' ' 

10 < ! ELEMENT recipients ( signatory) +> ' ' : : ' h ' ; ' v 1 * ** P/ * 

<!ELEJ^Tdate2;issued (date)V " " * ' " '' U ; ' ;i: ' w '* 

< i-ELEMENT date^signed' (date)> " :s - ' '° ^ ' 



<!!ELEMENT, transaction^ - 

(description, ^ ;i > 

p 1 -■" ^dat'e ;1 ' ' r ' 

< ! ELEMENT related^receipts 

( r e ceip t_I D, des crip t ion ? ) * > 

<! — ATTRIBUTES of the elements ' — > 



<!-- receipt — > 

<!ATTLIST receipt sof tware_version CDATA #IMPLIED> 

< ! ATTLIST receipt id ID #REQUIRED> 

< ! ATTLIST receipt type CDATA #REQUIRED> *r w 

'30 <!ATTLIST status (UNISSUED, ISSUED, IN PROCESS, FULLY SIGNED 
REJECTED) f #REQUI^ED> . - ~ s , t . ; ; ~ _ V 

<! — transaction — >. ,. ... f : ; , _ ^ . f . ; f ^ _v*/:. " W;\J* 
<! ATTLIST : transactidn id ID #REQUIRED> 
35 <! ATTLIST transaction type CDATA #IMPLIED> 

< ! ATTLIST transaction status CDATA #IMPLIED> 

<! — signatory — > 

< ! ATTLIST signatory rid-. -ID # REQUX RED> K ' ' c *'T'" 
40 <! ATTLIST signatory name CDATA #REQUIRED> 

<! ATTLIST signatory description CDATA ' #1MPLIED> >rr ' X ' 

< ! ATTLIST signatory role_in_transaction CDATA #iMPLIED> f " 

< ! ATTLIST signatory logo CDATA #IMPLIED> 

j * ■--.. . >■ :.v z." '3. f , VC'v-vJ ' - 

45 <!— date — > 

4 *ATjrLIS.T. date, r yearr; CpATA : . #REQUXRED>" ' J - -° ^^ xX " ! 

< ! ATTLIST date 'month CDATA #REQUIRED> 

< ! ATTLIST da te day. , CEtATA.-, # REQU I RED> r - joo: ^-'[T ■ - * - ; - 
. <!ATTLIST. date .hours .,CDATAi jlMP.LlEEEf>- " V - '■' cdJ 

50 ; <!ATTLiST, date minutes CDATA #IMPLIED> - ^ 

<!ATTLIST date seconds CDATA #IMPLIED> :; " ' ' :a ' ; '" £:;; ' f ™* ' ? ' 



55 



<! — receipt_ID i-n .-list of related^receipts ' --> 
<! ATTLIST receipt_ID id ID #REQUIRED> 

3> <! — end of DOCTYPE receipt — > 
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<!-- Example of a Electronic Transaction^ Document Body -> 

r <?xml .yersion,= n 1.0 u ^> : ;-- : Ji-^ v--> 

5 ^ RSCeiPt . d ° CUlnent v -f Sf ^^^fe;^^^' the &1 . 

t * below .-t> \ c f ,^ " : * -;\ r - ^ r; , > 

<tDOCTYPE^STEM ^ww . vereceipt, 

10 <receipt . 7: \ /. : . * *- ~ ^ 

software_version = ^Vefeceipt 0 01" ' "' z ' 

^Sel^ery" 4 CN104 °/ 7 2/8901/009 TX04/011S/5307 RKOOOOl" 
1C status =. "IN PROCESS" 

<issuer> . 

- ' <signatory - . - ■ * t * 

, ..' id = "^0199/853/4 CK1040/72/;6 901/0 ; 09" 

20 name = " Render Farms Inc." 

role_in_txansaction =' "Sender" - j . 

</issuer> . . , 

9 <recipients> 
5 <signatory 

id = "CA0199/853/4 CN2478/85/4769/055" 
name = "Pacific Data Images" 
e role_in_transaction = "Recipient" 

</ recipients> 

<date * ' ' J " ■ 

35 ' : . rr.-.:: .?n f i;-: j.'- 0.x-.- , ' Y ea *' = "1998" 

month = "09" 
< ^oi->~)W'±r .wr day =f../<l4f! >f '. 

hours = "05" 

. J'Ij oi wif; -I* .* l ym±nu%es^ n 41?\^ 

A(\ /:> 
• - . . </date^issued>.7 : >' 



30 



id = "TX04/0119/5307" 

boor,> ttrtXRe:.?? Fil e<*' Deli very" • ".I 0;-!'> .^10- 

status = "Done: Receipt Pendinq" ,^ 



year = "1998" . 
)' . - r - ' mdrith '= "09 TfI 

day = "14" 
~ ^ : ' hours ~= "05 

minutes = w 44» 
, : •'• - -- ; 7 * /> • 

</ transaction> 
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<rel'ated^receipts> 

<receipt_ID id = "CA0199/S53/4 'CN1040?72/89bl/b09 
TO04/0119y528.^.^pNppopi7/ 1 > - . • . . s - o..; ; ■ : ---*> 

- ; .5"i -" ' " ■■■■ ,: ^description "Request for service"/> : 

<receipt_ID id = "CA0199/853/4 CN1040/72/89'Ol'/6o9 
TX04/0119/5282 RN00001"/> 

.. description "Receipt, of materiaas'i/> — "" 

' " U "<receipt_iD id = "CA0199/853/4 CN1040/72/8901/009 
10 TX04/0119/5290 RN00001"/> • • U- 

<description : "Payment'!/> ^ r . W: .c; v j- - j :-r-<" 
</related_receipts> '.:.<. u ".r 0 10 -- "• i 

TheDatabase Representation 54 provides relational database specifications 

15 for fields corresponding to members of the aforementioned class(es), and tables 
establishing relations among electronic transaction documents (e.g. chains) and 
between electronic transaction document contents and external data. These 
specifications may follow standard SQL. 

The Published Representation 56 describes an electronic transaction 

20 document as it is transmitted between issuer and recipient. It uses an extended 
Markup Language (XML) notation, following the electronic transaction document 
data format given in the Open Trading Protocol (OTP) standard. 

The published representation 56 describes both the embedded data to be 
read by the Transaction Document Server 30; Transaction Document Client 70, and 

25 workflow system 90, and the appearance of an electronic transaction document (as 
in a web browser). The organization of the embedded data is referred to herein as 
the formal electronic transaction document. The electronic transaction document as 
it appears is referred to herein as the visible electronic transaction' document The 
formal electronic transaction documenticonsists of a document encoded according 

30 to a known BER (Binary Encoding Rules) standard, and signed according to the 
*£9Sf7 f S^ dard f or signing documents.alt contains the data elements listed below. 

Each signature in an electronic transaction documenfmay contain several 
information fields, in addition to the usual signauWalgorithm identifiers, signature 
certificate references and the encrypted digest itself. These fields may include: date 

35 of signing (UTC), meaning of signature (a coded field with values related to 
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receive4ackno W ledge^^^ 

may be added to the signed part of the electronic tr&sa^ii document. : 

, . For: cases nn which the issuer knows tliSf the^recipient will be using 
co mpat ible ;S oftware to process the elearoruc transaction document, the formal 
?. ..' e lectronic.transacti6n document may be ail that is needed. "However, if the recipient's 
software is unknown or known to be incompatible, ah alteWtive form of the 
electronic.transaction document, or multiple alternative forms, may be delivered 
along with the formal electronic transaction document. 

Each visible form* also- carries a short message explaining: the importance 
of the, signed,. non-repudiable electronic transaction document, how to save the 
-. electronic, transaction document, including the formal electronic transaction 
document to a,disk file in commonly used software, how'to obtain client software 
for electronic transaction document validation, etc: 

Electronic transaction documents can be embodied in different forms 
.transmitted via a number of different transport nlechahisms, such as HTTP (for the 
:. Web), via FTP:(for FileDrive) or by E-rtaU (for office mterchahge). 

• ■■ In the case of HTTP and FTP, the forms sent are determined by content 
negotiation. MIME may be used to combine the multiple forms. Additionally, the 
.formal electronic transactionddcum^ 
by base64 encoding and attachment of appropriate headers. ' 
■: v':The. s fonnd--relectro-n1c transaction "document j may { be generated by 
1 hierarchicaI ^ruction Of the m^*m^ii%& data below as an 

XMLdocument^TMsisthen^anomc^^ 
; QT^^na^specific^ion m^ri^m^M tte canonical XML 
objects digested, the digest is signed by t& issuer (e^ according to XML 
--.canonicalisatibn, algorithm Untamed'' in- OTP ; spec (OT>W Spec. v0 9 
scn3. 13;6.2)) Finally, the XML object, and the version identifier, digestalgorithm 
.dentrfiers, certificates, certificate revocation lists, and signer information (including 
the agnature) are packaged as a BER object according to the PKCS#7 rules The 
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. . . . signing and packa^iq§ i ^qc i ess may be recursively repeated to attach the recipient's 
^Snature if mu^tiple f s^atories arejnyolved ti ; ~ M - r l. n- ■ 

t J^ e d ?^ SBSr'IWM* the electronic transaction document may also be 
contained in an XML document, (»nstipcted ^rarcMcaily from the following data 
5 , item 5 according to 411 XML/dpc^ment type. definition/^ 

^ exa ? t tp be used conform closely to eh^er;the>iXNai/EDl guidelines or 
to the OTP proposed specification. Ele<rtrQnio > transaction doc^ent data may 
include: , ( . .. , r _ . iV . ; T . .•>' •. •■' ('<■ 

*?P*?^ e : ■•.version information (used to maintain backwards 
10 compatibility); type of electronic transaction document (includes information used 
to decide on future ^processing, for example whether this, electronic transaction 
document requires further signing); references to related electronic transaction 
documents; a unique electronic f transaction document ID; and content of the 
electronic transaction document. .., / 

The content of electronic, transaction document may include a description 
of the issuer and recipients, date, of issuer date the first signature was affixed to the 
document, description^ of the transaction, decorations to be included in the visible 
form of the document, and ^the payout ••.of the visibleifbrmi d .-• .: 

. . The issuers pprti|ca^ may be sent as, part of the 
document. A unique reference to the issuer's certificate, jponsistinf of the certificate 
issuing authorities distinguished name composedwithAeissuer'sdistinguishedname 
as given in the certificate is sent \^.^el«^i|i&tnms«^ndod^eMks part of 
the signature information define^, by the PKCS#7 specifications r,ch J± ft - 
. , .. ^ with^issuerts^errifi^^ as part 

of the returning electronic transaction document. - A , unique -reference to the 
recipient's certificate, consisting of the certificate issuing authorities distinguished 
name composed with the recipients distinguished name as given in the certificate, is 
sent with the returning electronic transaction document as part of the signature 
information defined by the PKCS#7. specification. 
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: ; - • The Transaction Document Server 30 : an* %m&cSon Documem CHent 
U .7Q.each incorporate* databkse'60. The database 1 ^ signatories table 62 

'. - a transaction docume^ table 64, and itransactior^u^ relations table 66 
Received transaction documents arid-messages are stored in the transaction 
5, ,. documents-table 64^^1trar^on'd6c«n^ Nations table stores chains of 
indexing hooks -that ^fererice associated electronic transaction documents: 
; i ^ ^8- 2 ; isanimu^ a tiondepictmgthe^^ 

document as used in accordance with the present invention. The core aspects of the 
, electronic transaction document 200 include the contents 202 that are issued by the 
10 Transaction Document Server 30, the encrypted digest 204, and digital signature 
206. The contents 202 may name the parties and contain the terms of the 
transaction, or reference the terms contained in a separate document. The contents 
202 are secured by digest 204 and the issuer's digital signature 206. The contents 
202, document digest 204 and signature 206 are sent to the Transaction Document 
1 5 Client 70, who verifies one or more of them and adds an additional document digest 
214 and signature 216. It is to be understood thai the electronic transaction 
document 200 is^one of * variety of different types of electronic transaction 
, documentsthat may be* implemented by the Transaction Document Syiem 10, and 
r v ^s:other:signatore>^ - 
20. „ ; > r . Eig./3' is a; flow chart illustratmg the lo^ of steps executed to 

, <^eandtransmita*^ obtam a digkal signature 

Mfrom^^single r^pierittas^hbwn^h Fig.'2; bireciing attention to ioo the 
-^sa^ 

a Transaction Document ID number, Description of the Issuer, Descritbn of the 
25 ,, ; cTxan^^ ; 0^^'6f the recipient; a^^efeVences Mother transaction * 
document s ,The content optioriallyYefers to one or more previous transactions (via 
the,r unique identifiers) to Svhich this transaction is related. Transaction content 
usually describes or refers to contractual terms of the transaction (e^ describing 
.terns purchased, price, etc.); describes all parties to the transaction, including their 
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name and (possiW^ a u^iigue identifier, and role iijjthe>transaction; and requests the 
recipient to sign^and^ ngurn a copy qf the^ejectrQnic transaction ^ document. 
Transaction document content is supplied to.<the,Tcansaction Document" Server 30 
from the workflow system 90 via API 40. - , . , . - . . • . 

... . Continuing to step t 302, the Transaction Document Server 30. theft inserts 
the issuer's digital signature into the electroniq transaction document and encrypts 
the electronic transaction document, using thelssu^s certificate (such as available 
fr ? m , Verisi P^ ^ generating a digest on the encrypted form of the electronic 
transaction document content.. The digital signature verifies the identity of the 
participant and indicates, agreement to the ; terms described or implied in the 
electronic transaction document . Signing is the means by which the identity of the 
issuer is rendered non-repudiable. The method for signing XML documents 
proposed for OTP is described in the Open Trading Protocol Specification, Ver. 0.9, 
Jan. 12, 1998, incorporated herein by reference. The issuer then generates a tamper 
15 proof seal by creating, for example, an encrypted , checksum on an encrypted 
encoding of the electronic transaction document's contents. ThiSitamper proof seal 
is the means by which the content of the electronic transaction document is rendered 
non-repudiable. The issuer then encrypts- the elect^qnic transaction document for 
transmission. Encryption can tajce place at theQPR level qr at ; the level of the 
20 communi< i ation ? u ^^stem, or bpth, and. the .communication: sijbs^stem may or may 
not add its own further ciyptographic functions. ;3fej^0ipns:9f the. communication 
subsystem when not shown expKdtly ^ 

br in the ir accompanying . descriptions, , . should., bg^^mderiStqod to, be: :present 
nevertheless. , ... , -i. n „. ..^r^vr * 

At step 3 .°1 the ^ Transaction Doqument ServerSO . transmits the electronic 
transaction document to the Transaction Potent Client TO^This transmission 
may be implemented using the Secure Socket. Layer (SSL). The electronic 
transaction document can also be sent using any network protocol such as HTTP, 
HTTPS, FTP, SMJME email, etc. The Transaction Document Server 30 may also 
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V . .h=»"rkflow 9 0 t ha t a„ electronic <™*tfiRtafflS, has beeped M d 

: i a;signature is pending/ i - e ^ 4 »^ ; * o'oc-h n:::J:»£3: n . . ; 

- ; ^^P'306the.TransactionDocumenfCH^^^^^ 
^.electronic transactfon document; Control continues to step 308 where the 
.TransactionDocument Client 70 validates^ issue* digital signature. If the digikl 

rejects the electronic transaction document, notifying both the recipient (step 312) 
andtheTran^ctionDo^ 

If the issue* signature is valid; the Tt^^Bo^C^ 70 
presents the document to the recipient for review ( step 3 1 6). Tne recipient may be 
enher a person, viewing the- document' in a browsed of email message or an 
automated system, parsing the XML-tagged data fields of the document. 

The recipient may 'decide either to accept or reject the electronic 
, transacts document or delay this decision It is to be understood that acceptance 
of the electronic transaction document indicates acceptance of the content orterms 
^nt^intheelectromctransactfo^ 

that the elecfronic . traction document ^ reeked. Depending on the 
apph^on, ^recipient may also be able^to add sbine^ to the electronic 
t™sacUond6^ment,*i^ , 

u , v , If the recipient decides^ reject ee ^^^^^ ^^ 

^rejection 

^t^Ma^^^m^^^ m ^ wit^refere^ce to%ig: 4; - * 

or she iarst carries out any actions required by the elect&nic I Action document' 
Jnpai^cular,^ 

fields, or requests to obtain and- submit other ! documents (such as notarized 
transact™ documents or affidavits) and cite their reference numbers on the 
electronic transaction document. In the either case, the actions may require some 
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time to comp^tfj^.tjie, recipient may choose .to delay signing and returning the 
electronic transaction document. At step 3 1 8 the Transaction Document Client 70 
-? or? ?K* e W^?n ; 4P cume ^ in its database 60,' so that the recipient may retrieve 
it when ready to sign. The Transaction document Client 70 then notifies the 
Transaction Document Server 30 (step .320) of the. delays ' At step 322, the 
Transaction Document Server 30 makes an entry in the transaction' documents table 
64 reflecting that the recipient is deferring signing, and notifies the issuer at step 324. 
. Once, the electronic transaction document has been reviewed, and any 

required actions completed, theTransactionX)ocument Client 70 signs the Electronic 
transaction document wjth the recipient's digital signature (step 326), thereby 
authenticating it and sealing any added content against tampering. This signed 
electronic transaction, document is referred to herein as an acceptance message, and 
refers to the unique transaction identifier on the original -.electronic transaction 
document and indicates acceptance of the terms. The acceptance message may or 
may not include all the terms or other information contained in the original electronic 
transaction document, depending on the particular application.. At step 328; the 
Transaction Document Client 70 ^stores a copy of .the acceptance message in its 
transaction document table .64, The Transaction Document Client '70 then encrypts 
and transmits the acceptance. message,ba,ck to the Transaction Document Server 30 
(step 330). TWs.tiraiisnpssion SSL, and may transmit 

.J£P ies °f £ to third parties, such as auditors, Depending on the embodiment, this 
routing to tiiird parties c^uld be handled by the Transaction Document Server 30 or 
left to the workflow \system. The TransactioRvPociime^ the 

°?^?" d f :???n^^ ti "^ fending -J^ 0 ^.3^ns^fen.©Qcuntent Client 70 an 
acknowledgment message. ..,=,... , v,.rr uo tzhurj iz<ft. sH* -v 

Directing attention to. Fig. 4, when the ^recipient rejects the electronic 
transaction document (step 400), the Transaction.Document. Client 70 ; prepares a 
rejection message (step 402). The rejection message is an electronic transaction 
document that refers to the unique transaction identifier on the original electronic 
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transaction document and indicates rejection dfthe tefihs^t step 404 the recipient 
.„ W> the rejection note with his or her digital ^^a^/ m rejection message is 
then encrypted (step 406) and transmitted to ^Trm^^bocun^tt^erver 30 
,(step408). The Transaction Document ^Server 30 receives the encrypted rejection 
5 ^ e '**» 41 ^ Iftherecipient's 
,„ signage isinvalid ; *he Transaction Document Server 30 reports tothe Workflow 
system 90 (step 414) and the Transaction Document Client 70 (step 416) that the 
s.gnature is. invalid, , If the recipient's signature is valid, the Transaction Document 
Server 30reports tothe workflow system 90 that the original transaction document 
sent to the TrrmsactionDocument Client 70 was reje^ed by tHe recipient (step 4 18) 
TheTransactionDocumentServerSOmayperformtheop^ 
sendmg to the Transaction Document Client 70 an acknowledgment message. 

Anelectromctransactiondo^ 
For example, approval cycles or notarization of the transaction may require third 
party s.gnatures. Signatures may be appJied in parallel or cascaded. A cascaded 
stature testifies, that the signatory has inspected the other signatures, and once a 
cascaded signature has been^applied to an electronic transaction document, no 
. add,t«>nal parallel signatures can be permitt^ above the cascaded signature 
...However, obsignates may be appliec in ^eltothVca^ded-s^hature and 
afiirtherleyel (or levels) of evaded signamfesmaVbe^ded: * r ; 
: ,0 , , Different protocols. for collecting multiple signanires for an electronic 
^sac^^oQument may.be^ecuted by the T^sa^oh Do^imem System 10 
V* Parallel^otoc^l (Fi gi 5a> sendees dhheel^^&tel^d^em 
to all s.gnatories concurrently, and theti ^a^Wre^s <>nto ± single 
^:^le^^ The Serial>rotocol (Fig. 5b) passes the 

electronic.transaction document to each signatory in tu^ so that each digital 
mature endoses the previous one. In both the Parallel and Serial protocols the 
procedure for gathering each signature is similar to steps 304 -" 334 described in 
Fig. 3. The Serial Protocol differs from the Parallel Protocol in that the Serial 
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Protocol may a£orJ f the signature gathering process if any one signatory rejects or 
submits ai\ .i^lid ^(togment. It notifies, the workflow system, whith decides 
wheAer to cpntinu^ ^ / f j : r ^ 

^epting attention to Fig. 5a, tlife. Transaction Document Server 30 
prepares transaptipn document content atvstep 5Q0 and inserts the issuer's digital 
signature into tjie electronic transaction document and encrypts 5 the electronic 
transaction dpcument at step 502. Steps 500 and 502 are performed iii a similar 
manner as described in steps 300 and 3 02i of Fig. 3. ^Continuing to step 504, for 
e ? ch ^ he fecipi^Jits involved in the multiple -signature parallel protocol, similar 
steps enu^r^djn steps 304 r 334 of Fig. 3 are performed. If one or more of the 
received response, messages contain an invalid signature, control proceeds to step 
506, where receipt of; the invalid signature is reported to the workflow 90 and the 
client (508). The optional step 510 may be included where the Transaction 
Document Server 30 stores the partially signed document in the transaction 
documents table 64. However, if all of the recipients have responded with properly 
signed response n^sssages, control proceeds to step 512, Where the Transaction 
Document Server 30 embeds all of the received documents in the original electronic 
transaction doqumenf The, folly signed documentors stored in ! the transaction 
document table 64 at step .514 and : tfa$ \yorkflqw90 is notified' at &6p 516 that all 
recipients have ^ signed jth^ do iCuinentv The fiiUy signed docuMent is erictypted at step 
518, and,pqpie^re ; SQiit tp each;of the recipients at step 520. * Completing the 
T . P 1 " 0 ! 0 ?? 1 ^ ?tpp ( 5?2 > ; pacli. of the individual Transaction ©dcumeht ^eiients 70 

f# b $°^g*^ signed abcutnent and stores 

it in transaction dpcumeqts. table €^.| , nr . r , vhi iny;' ;a<^ ^ ^ 

v.- A c^ca^ signature te^fies thatcthe s other 
signatures, and once a. cascaded signature has been applied to an electronic 
transaction document, no other parallel signatures can be permitted. However, other 
signatures may be applied in parallel to the cascaded signature (with the same 
meaning) and a farther level (or levels) of cascaded signatures may be added. 
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Directing attention to Fig! 5b, the serial protocol i^ec^d to obtain cascaded 
statures. The Transaction Document Server 30 pr^ar* transaction document 
conte m( ste P 550),ffi S ert^ 

: dpCUment and encr yPts the electronic transaction document (step 502). Steps 500 
and 502 are performed™ a similar maimer as described in steps 300 and 302 ofFig 
,3., Continuing to step 554; for the first signatory in the serial p^ocot a signature 
collection procedure is executed, similar to the steps enumerated in steps 304 - 334 
of Fig ,3: If the received response message contains ah invalid signature control 
proceeds to step 556, where receipt of the invalid signature is reported to the 
workflow 90.and the client 70 (step 558). The optional step 5 6 6 may be included 
where the Transaction Document Server 30 stores the partially signed' document in 
^etra„s a «iondocu m enttable64. Ifthe recipient responded wkn a properly signed 
response message, control proceeds to step 562, where the Transaction Document 
Server 30 embeds the received signature into the original electronic transaction 
document. To send the partially signed document to the next signatoryin the chain, 
control returns to step 552, where the partially signed document is signed and 
encrypted. This sequence is repeated for the remaining signatories. When the chain 
.scompleteandaHs^^^ 

Wthe transaction document table 64 at step 564 and the' workflow 90 is notified at 
step 566 that all recipients have signed the dbcUmei* Se fully signed document is 
encrypted^ st^56^an<3 copies are seht^^ of the ^ recipients at step 570 

, Gc^letmg.the^otocolMstep'572, each of the fe^^ 

>^»*™b e lon^ 

■ ,:and stores it in* ittfown^dataoase; J : - s ' iT ' ; ■>■•-> 
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-NON-PARTY PARTICIPANTS • ; " ' 

" Some Action documents, such as purchase orders for amounts above 
a set amount, may require the signatures of non-party participants, such as notaries 
supervisors, or similar entities to complete a transaction, the present invention 
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implements-thege types of transactions in an online setting by allowing non-party 
participants to use the Transaction Document System, lO to affix his-fir her digital 
^ i ? n ?;^ ure . t0 .. tne , ^^Pfuc tr^ansartion document, * Figs.. '6a and: 6b illustrate the 
logical sequence of steps executed by the present invention to. accommodate the 
signatures non-party participants inelectronic transaction documents- ForiMstrative 
purposes, thes^ examples incorporate the digital signature ofa notary, but other non- 
party participants may be used as well.. :. <i;?c ■ 

fig- 6a is a i flowchart illustrating the logical sequence ofsteps that execute 
a notarized transaction according to the present invention. In this scenario, a notary 
participates in the transaction between a merchant (issuer) and customer (recipient). 
The merchant and customer are, conducting transactions surrounding the sale of 
goods or services. The merchant uses a Transaction Document Server 30, and the 
customer and notary use separate Transaction Document Clients 70. Directing 
attention to step 600, the Transaction Document Server 30 creates an electronic 
15 transaction document, affixes the merchant's digital signature, and. encrypts the 
document in a similar manner as described in steps 300-302 of Fig: 3. Atstep 602, 
the issuer transmits the electronic transaction, document to the notary. This 
transmission , may be implemented. .using -the Secure Socket Layer (SSL). The 
electronic transaction document can also be sent using; any network protocol such 
as HTTP, HTTPS, FTP, SMI^.email, etc. The Transaction Document Server 30 
may also notify the workflow 90 ^at an electronic transaaion document has been 
issued and a signature is pendjng... At step 604„the AGt^*e^v<^a^<yeriffes the 
ele ^ 0 ™ c ^ tr ^ s *$° n . ^ 

encrypts a checksum of the electronic tran^c^pn.^c^an^it. and notarizes the 
25 electronic transaction document by affixing its digital signature to the electronic- 
transaction. The notary may also store a copy of the electronic transaction document 
in a database for future reference. ^At step. 606, the notary transmits the notarized 
electronic transaction document back to the merchant. The merchant receives the 
notarized electronic transaction document at step 608. The merchant may verify the 
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signature of the notary and store h in a database fo^tUf^eference and proof that 
the eleptronic transaction document was .notarized ' -At^sfep 610, the merchant 
. trar^n^ to the customer. The nierchant may 

send either the original electronic transaction document or the notarized electronic 
transaction document, depending- on the business requirements. At step 612, the 
customer receiyes,the electronic transaction document and verifies the digital 
.signatu^ of , the merchant. The customer may also Verify" the notary's digital 
signature, if the notary* signature was appended to the electronic transaction 
document. The customer may then process the electronic transaction document 
Processing the document may include storing it in a database for future reference 
presenting the electronic transaction document to a user'who could interactively 
approveordenjaheelectronictransaction document, or entering the document into 
a purchasing system, accounting system or document management system. At step 
614,thecustomergener*tesan^^^ ^ 
received electronic transaction document. This response can be either an approval 
denial spending, notification. . The response can optionally refer to the original 
electronic ; transaction document by its ID number,orthe checksum and signature of 
the merchant, or by the notary. Alternatively, the response can actually contain the 

r QriginaJ 1 eIectrpnic transaction document itself as part of the response electronic 
trar^actipn document, . The, response ^electronic transaction document is 
checksump^d and. signed !W ith the customer's private key: 'Tne response is then 

.transmitted tp ; th Sr merehant: ,At. step 616;: the merchant receivestte electronic 

■^^m^^on^oc^rtespotistv ^ce^^^&v^g the 
customer*dighalsignature,stormgtheelectrome^ 
^'^^^^ 

At step 618, the merchant, transmits a copy of the electronic transaction document 
response to the notary. The merchant m ay affix Ws digital signature the electronic 
transact™ document before sending. At step 620, the notary receives the 
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. . ; electronic trai^efiQifidocument response from the merchant. The notary may then 
verify jthe sigjiatyres <frf>the merchant and customer; and reconcile tfie electronic 
.transaction dqcy5n#$t response with the original elesetrbnic transaction document. 
. The notary may also store the response hi a database for future reference: At step 
6£2? notary transmits, a response message b&ck to this merchant indicating that 
t^e pustomerVresponse was notarized atid recorded. The riotaiy's response message 
may also hp an. electronic transaction document. The ridtary^ response ntey contain 
, : , , simply a reference to the original electronic tranisactiori document and the electronic 
transactipn .document response from the'bustomer^br it may contain the actual 
10 original electronic transaction document and the electronic transaction document 
response. At step 624, the merchant receives the notary's response message. The 
merchant may then yerify tjie notary's digital signature and initiate or complete a 
transaction, such as shipping goods, performing services and the like. 

The , explanation above describes a process in which an electronic 
15 transaction document ^must be notarised before sending, the ddivery and 
, approval/denial/pending of the electronic transaction document is notarized, and the 
entire process must.be completed before the tran^etionis finalized: Alternatively, 
the merchant could start the process when the dectrbnic transaction document 
response is received from the; ^customer in. step^61 6; aM the final notaiizdtibh could 
20 , be performed for record keeping purposes only t Thef Merchant could also process 
the transaction after step 616, and attach the rfesults of that ^^ tr^sactibn to the 
message that is sent in step 61 8 tp*he notaryto pfrowd&evidence that ih^tiansaction 

, , - ^X^^^^^Pfj^: for the initiaticmvof the<c^if^khd a-secoi^ c ^^%r the 

25 complex -r'-^il' >rs ^v^u^a *:*&A : .t> ?'*Knno> • 

Fi S P b describes an alternative notarization protocol wWch is 
protocol described in Fig. 6a, but includes interaction with two separate notaries. 
This allows both parties (merchant and customer) involved in the transaction to have 
the entire process audited by their own trusted third party. The notaries may 
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, .coUectively reconcile the transactions \^™tte^6m^ catoynm. In this 
, protocol, itis assumed that the merchant has sae^iio^X^ife-curt™^ 
, : sdect^-nptary B. .Again,, the-merchint uses die rffi^o'Afecu^ W 30 
: and the customer, notary A and notary B eacK use their own Transaction Document 
,5 Client;?©. Directing attention; to step 650, the ^ merchant's Transaction Document 

, signature, and.encrypts the document in a similar manner as described m steps 300- 
302 of Fig. 3., At step 652, the merchant transmits the electronic transaction 
document to notary A. This -transmission may be implemented using the Secure 
10 S 0 cketI^yer(SSL).Theelectronictran S acti 0 ridocumem 

network protocol such as HTTP,'HTTPS, FTP/SJiQME emaii, etc. The Transaction 
, Document Server 30 may also notify the workflow 90 that an electronic transaction 
. document has been issued and a Wignature is pending. At step 654, notary A receives 
andverifiestheelectronictransactiondocument. Notary A's Transaction Document 
15 , Client 7 0; then encrypts a checksum of the electronic iransaction document and 
, . notarizesthe electronic transaction document by affixing its digital signature to the 
^ec^transa^ 

., ,7 document in ^database for future referenced At step 656, notary A transmits the 
notarized electronic transaction document back to the merchant. The merchant 
20 ,, receives 7 the notarized Electronic %arisadion ^ocument at step 658. The merchant 

may venfythe signature of notary A and store the\iotariied document™ a database 

l0 4br,^^^ 

^ru^tajfe* M step 660,the met^^ S^cument 
^thec^p^Thgmetchahtmayt^ 

dowe^^^^ depending on the 

busme^re^^ 

document and verifies the digital signature of the merchant. The customer may also 
venfy notary A 's digital signature, if notary A's signature was appended to the 
electrons transaction document. The customer may then process the electronic 
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^ s ^9"^?W^ft^ c ^ s ? in 8. the document may include storing it in a database 
for future ^ refe^en^ pre|?enting the electronic transaction docuirfent to'k user who 
could interacjtiyej^ apjjrove.ordeny the,electronic transaction document, or entering 
the document into a purchasing system; ; accountings system or document 
management system. At step 664, the customer generates an elec^onic transaction 
document that responds to the received, electronic, transaction- document This 
response can be either an approval, denial, or pending notification; The response can 
optionally refer to the original electronic transaction document by its ID number, or 
the checksum ang, signature of the merchant, of the notary. Alternatively, the 
response can artualjy, contain the original electronic transaction document itself as 
part of the response electronic transaction , document:; The response electronic 
transaction document is checksummed and signed with the; customer's private key. 
The response is then transmitted to notary B : At step 666, Notary B receives and 
verifies the response, and notarizes the response by creating a digest of the response 
and signing the response and its digest with its private key. Notary B may also store 
a copy of the respoiise.in a database for future reference. At step 668, notary B 
transmits the : notarized response, back to, the .customer,: At step 670, the customer 
. receives the notarized response and ^nay, verify the -signature of notary B . vThe 
customer may. store the notarized response in a database for futare reference and 
•. pi °?f } ha y, — e docu ^^^. n 0^fized ; At step 672; the customer transmits the 
response to the .merchant ^ T^e customer may send the brigi.«ial ; electronic transaction 
d °J um ® nt ; resp °?r® or i n ?j? a ^ d f ^Pons^ iAt step 674, the merchant receives 
, the J^onse frpm|he r pu^pnier- The merchant, may. then verify the digital signature 

re$ P°Ps e -,i- Brpcessing i ;rnaydncl5id& storing the 
response for future reference, prpcessing by an order processing system, etc. At step 
676, the merchant transmits a copy of the response to notary A* The merchant may 
sign the response before sending. At step,678, notary A receives the response from 
the merchant. Notary A may verify the signatures contained , in the response, 
reconcile the response with the original electronic transaction document^ and attach 
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; its distal signature to the response.. Notary A may-also *tore this document in a 
da^ 

^^-f^^^mste^s response^Bot^aria recorded This 
message ma y also bea electroruc : transaction document, and may contain simply a 
reference to the original electronic transaction document and theresponse from the 
customer, or it could p 

the response, At step 682, the merchant receives the message from notary A, and 
may ver^notary A's digital signature. The merchant then processes the message 
Tins could mean actually initiating or completing a transaction. < Similar alternatives 
are available as those set forth above with respect- to the notarised transaction 
illustrated in Fig. 6a. ... ? 

WhileFigs. 6a and 6b describe the interaction of notaries in the operation 
of the Transaction Document System 10, other third party signatories such as 
auditors may be substituted for notaries in the above examples. 

VERIFICATION 

....... When, an electronic transaction document is received, either by the 

Transaction Document Client 70 when the document is issue* by the Transaction 
; ?P^ nt Server ^, , 0 r ? when the; Trari S action Dodument Server 30 receives a 
r^pons^ a^d is required to ; sign,and retransmit the document, the ^ 42 may be 
^summoned hythe user to display the document- Directmg arteritis to Fig '7a, the 
WM^* °mvm. :,lhe dectrdmc^s^dnvdocu^hf is flayed in 
m*SI* Wsyiew the^ntents-of the ^ocume^ ^ print the 
^^^^^^^hmtoffJOA^^ sig^Un&n 706 
.pr the^^tton.70^ .^rm.^Ml^^^f,,^^^ £■ 
acceptance or rejection of.he :j electfonic transaction docunie^ Again, it is to be 
understood that acceptance or rejection refers* acceptance or rejection^ of the 
con^entsortermsofthedocumentrathermanacc^^ 

of the document. In cases of high volume document traffic, the UI 42 may be 



n 



• • • # 

,WO .00/25245 



10 



25 



PCT/US99/24570 



-33- 



, , , configured tp,,perfpipv the iaccept/reject/delay process automatically: The show 
, related button^lPasUows a user to view a list of kored electronic transaction 
/ ., documents that ;are -related :to the currently displayed document (Fig. ' icj. 
,i ; Jn addition to accepting and rejecting received" electronic ^transaction 
,5 .documents, the UI 42 provides auditing functions Wt ti^kmgV' Verifying, and 
generating reports on electronic transaction dbcumehci stored iri the database 60. 
By, pressing the select document button 712, screen '720 (Fig: '%) appears and 
. displays information related to the transmission of electronic transaction documents 
and related responses. The displayed information may beused to ensure delivery and 
to verify acceptance or rejection. The user may choose to track all documents, or 
documents of a selected status, such as accepted documents, failed transmissions, 
rejected documents, or indeterminate transmissions. Additionally, the user may 
specify a date from which tracking is performed. Once the above selections have 
been made, a list of documents matching the user's query are displayed below, 
1 5 organized by fields. The fields may include document description, which is usually 
an identifier that has been attached to a particular document; custdinef name, date 
and time the document;was issued, status, and a field indicating whether related 
documents exist. •• ., vs/.twvs^ • pz><>; ..." .>,■'■,.>• :> t. ■:■ ;.■ v. «";. ' _ 5 

••• K> t Mser..W^»es tQwewthe list of related documents; pr&s^g the Show 
20 ^ Related Pocuments button f 22 will summon. the delated DocUment:^ Screen 730 
. , f ; v (Rg- 7 C ) : , By pressing , the link documents buttotf 724, the user is guided through a 
. i ; v*?™^*^ ^9^5 the user- to yiew lists of stored documents; sel^bcumehts, and 
I f . ;: e^|i^.|h^.b^een the selecteddoeuments andth'e curreiit electronic transaction 
» vT^S^^.T^M <?f currently tinked-^Ioaimeftt^ih^^ieii'^e dispfayedon the 
?r^ at v d ,7^ ansa 9 tion < ,P ocurne rttsoScreeh~730. Ahei^very/%e { wo ? rMow ! slo may 
automatically establish; the relationships between electromc'ti^saetion documents 
according to their role, in a transaction. Links between electronic transaction 
documents may also be removed through a similar process by pressing the'remove 
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Iinks button 726: Manipulating links betweeri elec^cWaction documents may 
be perfonned oriboth the Transaction DocumfeAt^rver id or Server 70. 

The UI 42 also allows a user to audit any* dbcurnem 'or group of documents 
storedthedatabase60. By pressing the audit transaction documents button 728 the 
validator mo'dule'44 is invoked to Verify that a selected document or group of 
' ;d * c »*»* *as:n6t%ee„ alfeVed sinte the putative date of issue and that signature 
- certificates are valid. The results may be presented^ the user in tabular form 
Electronic transactibn documents held by separate parties be reconciled in this 
mariner to verify that they are 'identical: ' ''- ' 

■ ■ - Screen - 730 displays and organizes ^1^ of documents related to a 
document selected from screen 720 according to reference number, type, date of 
1S sue,and issuer name. Omer^rrnaiioff may also be displayed if desired Since 
cross-references to electronic transaction documents' may form an unbounded 
network, an electronic transaction document network containing only direct 
references to and from the current electronic transaction document are displayed 
The user may then explore the chain(s) by selecting another electronic transaction 
-.-document and -expanding h 'in rami " : ^ ^ ■<■•-■* 

and re<^refer^^ the mbsf reiev^m? the UI 42 also may display a 

subset of the ^MiHn^^o^^ network fanning out from the current 
.electronic transaction document ^and including elec^rbriic transaction documents of 

.rdeyantctyp^ WseafchrnayW 

-stopatwele^cfrans^ 

items^-the elid<bm^dis>TayW ^ 
^^^W^W^^) io iridicate that the* user c^view more by 
sele^g^-For example, the docu^ , 457 may 

be selected according to the following rules: 

1) Include electronic transaction documents directly connected to the 
current selection 
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2) Include^ electronic transaction documents involved in & Purchase 
OrdejworMawfthatis, whose typhis ..oqeof*B0,£Q Confirmation, Sales 

_ Draft, APR, pi; Delivery) f> - f; ^,.\„.- ; 

3) Exclude other electrom^^^ 

5 Rg- 7 d is a flowchart shp^vi^g the steps required to audit electronic 

documents stored in the electronic transaction d<^umer$t$ table.64 iAt stej) 790, the 

user selects electronic transaction docqments ^ i n screen 720. 

Selection may be perfonned by n^pulafing; a mouse or other pointing device 

included in the computer system, onby pressing keys on a keyboard. At step 792, 

10 once the desired selections hays been made from the list, the user selects the audit 

transactions button 728. t By pressing the audit transactions button 728 when 

electronic transaction documents have , been selected frpm the list, each selected 
■ ■* ■ * * 

document is^ passed to the the ( Validator module 44. The Validator module 44 

inspects the digital signatures and encrypted digests/covering, the documents and 
15 notes whether any documents are unsigned, have been tampered with since the 
documents were signed, or suffer, other verification prqblems, : At step 794, the 
results of the audit are reported to the us ; er. , Reporting may .achieved through a 
variety of methods, such ^ an d 
displaying a table containing ; fields such asdocument nam§ and the result of the audit 
20 for the document, or cjther meaningful representations of the auditing results. - 
F «g 8 is high-level bloc^^ 
system haymg a computer program that causes the computer system*o perform the 
method of the presenynyention.. The Tr^aaion.^ocumejit. Server 30 and the 
: Transaction Document 70 ar^both implemented on computer systems such as the 
25 one shown in Fig. 8. The computer .system 846 .mdudes . a processor. 830 arid 
memory 825. Processor 830 may contain a single, microprocessor, orr may contain 
a plurality of microprocessors for configuring the computer system as a 
multi-processor system. Memory 825, stores, in part, instructions and data for 
execution by processor 830. If the system of the present invention is wholly or 
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v-ntheexecutable^^iftoperation.- ^o^^^ieianteofd^c 
random access memory '(DRi^i) as Well as gV speed rache memory. 

The system 846 furthVincludes i mass storage* device 835, peripheral 
5 . dev,ce( S )840,m^^ 

••.sub^^O^di^y^S. For simplicity, the components shown in Fig 8 
are depicted as being connected viaa single bus 880. However/the components may 
be connected through one or more data transport means. For example, processor 
830and m emory825maybeconnectedviaal^ 
10. S tor^edevice8.35;peripWdeMce(s)846;^ 

and graphics subsystem 870 may be cohnectedW oneormore inpuOoutput (I/O) 
buses. MassstoragedeviceSSS; whi^ 

r ^ ° r ** drfve ' is a no-volatile storage device for storing data and 

mstruchonsforusebyprocessorSSO. In another embodiment, mass storage device 
15 835 stores the computer program implementing the method of automating a 
- rmcroelectrohic mahufacturi^ : process for purposes of loading such computer 
program tomemory 825. The method of uVpresent invention also may be stored 
in processor 830; l ' 7 - ' - ^ ^ . i ; t ; 

' Po^bkstoragimfedmm drive gfiOop^ateinconjun^onvvhhaportaWe 
20 -.non-volatile' storage medium, -ch' *s a floppy disk; or other computer-readable 

■ ■,*.c«* i «WBB«.*^iaha' tf «,e 'preieW' i^on for automating a 
^croe.«Uoto^ uraetu ^ pr ^ is ^ on suchiportablemedium, and is 
r.-.- , input ,„ ,„e eompnter^stern H^via ponabte aorage medium drive 860 
25 - , PeHphoa. device*) 840 may inCudea^tvpe of compu.ee suppo,, device; suchas 
an u.pu./oun*., (,/Q) interface. ,o add addition,! ftmctionality ,„ ,he computer 

, ^846 ForexampHperipheraldeviceC^MOmayindudeanetworkinterface 
card for mterfacing computer system 846 to a network, a modem, and the like 
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In P« t .device(?) 855 prpyjde. a portion, of a user interface. Input device(s) 

i ^ 0 ™f ti ?5 T ^*J^ t ^., d< 5Y i ^. sudj^.^n^s^a^kbiOl,-. stylusx>r cursor 
direction keys. In order to display textual .and _ graphical information, the computer 
5 system 846 includes graphics subsystem 870 and display 885,, Display/ 885 may 

display devices, or means for displaying, that enables a r user , to , interact with the 
computer program to configure the application objects/ and implement the 
workflows. Graphics subsystem 870 receives textual and graphical information and 

16 processes the ^ information for output to display, 885. Display 885 can be used to 
display an interface to interact with the computer program to configure the 
application objects and implement the workflows and/or display other information 
that is part of a user interface. The display 885 provides a practical application of 
the method of automating a microelectronic manufacturing process since the method 

15 of the present invention may. be directly and practically implemented through the use 
of the display 885. Additionally, the. system 846. includes output devices 845. 
Examples of suitable output devices include speakers^ printers, ,and therhke. 

The devices contained in the computer system 846 are those typically found 
in general purpose computer systems, and are intended to represent a broad category 

20 of such computer components that are well known in the art. The, computer system 
' 'y "of Fig. 8 illustrates one p^om^ch.cm.be^sea for practically implementing the 
method oSfithe present invention, Numerous, .pjher platfpimscar; also^ffirc such 
as Macintosh-based platforrns with 
different bus configurations networked platforms, muJti-Rtocessor. olatforms other 

25 personal computers, workstations, mainfrarnes, navigation .systems^ and;the<like. <: . 

Alternative embodiments of the use pf the method pf the present invention 
in conjunction with the computer system 846 further include using ;o,ther display 
means for the monitor, such as CRT display, LCD display, projection displays, or the 
like. Likewise, any similar type of memory, other than memory 825, may be used. 
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Other interface apparatus, in addition to the component interfaces, may also be used 
incfedmgalpha^umerickeypads, otherk^^ 
■ as a mouse, .trackball, stylus^cursor or direction %? V'W**- - : 
It can be seen that the invention is hot fiArted ioiise on ahy single platform, 
and may ^configured for use with ^eciafized business applications. While the 
, myention-has been describee! with respect to specific embodiments thereof; „ is to 
be understood that numerous modifications are possible within its sconef 
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4 
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....... . . . ^i^xva-s " ■">■'- CLAIMS ; . •■ • .>,.,." 

. ..}; . , ™^^ < |-.fPfsB?^ blishill S a transaction; comprising the steps of: 

engaging in ^ .transaction revolving .atileas* first and second party 
participants and at least a first non-party, participant; ■ --. • . . • ' 
::.-v , Providing to said first non-party i^dpant-san dectforiic ''transaction 

document, non-repudiable by said .^'fa^participant :and>describing said 

6 transaction;..... ... „.. .,y r . 

7 in response to verification by said first non-party participant of at least one 

8 aspect of said electronic transaction document, adding an indication of said 

9 verification to said electronic transaction document and providing said electronic 

10 transaction document to said second party participant; and 

11 in response to acceptance by said second party participant of said 

12 transaction as described in said electronic transaction document, providing to said 

13 first party participant an acceptance note, non-repudiable by said second party 

14 participant and evidencing acceptance of said transaction by said second party 

15 participant. 

1 2. A method according to claim 1, further comprising the step of said second 

2 party participant indicating manually said acceptance of said transaction. 

1 3. A method according to claim 1, wherein said step of providing said 

2 electronic transaction document comprises the step of affixing a digital signature of 

3 said first party participant to said electronic transaction document. 

1 4. A method according to claim 1, wherein said step of verifying said 

2 electronic transaction document comprises the step of affixTng'a digital signature of 

3 said first non-party participant to said electronic transaction document. 
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1, 5-. r , A method ; :accprdiiig to" claim 1, wh»eW'sa*f%tep of providing said 
; .electronic transaction document to said second part? participWcc^prises the step 
of including with said electronic transaction document an encrypted digest covering 
4 at least part of said electronic transaction document. 



1 ; 6 - , A method., according to claim -1; wherein said step of providing said 

2 acceptance note comprises the step of affixing a digital signature of said second party 



. 3 , „, participant to. said acceptance note. 



1.7. A,method according .to claim- i; wherein said step of providing said 

2 acceptance note comprises the step of including with said acceptance note an 



encrypted digest covering at least part of said acceptance note. 



1 ..., : 8. Amethod accordmgtoclaiml;furtherco^ 

2 to receipt of said acceptance note,, providing a response acknowledgment to said 

3 second party participant acknowledging receipt of said acceptance note. 

1 , 9 . . _ ..A method according to claim 8, wherein said step of providing said 

2 , , ,. response acknowledgment comprises the step of verifying 5 adequacy to said first 

3 party participant of said acceptance note, and wherein said : response 

4 ad ^tedgniemfurtto 

5 .P a .r t XiPartieipant.i.:^ ,»v*«v.- .A rsLv .:. •^■"■jr^-.i . • ibs- . CI ( 

.ftOij^r .>•-■"} hh-'< 1.; .V->- ^1 2> .U..f. J' >:rtY:. 

1 10. A method according claim 1, wherein said step of providing said 

2 V ^acpeptance,.notefto saidfirst^parr^ the steps of 

3 providing said acceptance note to asecond noh-party participam, and in response to 

4 verification of said acceptance note by said second non-party participant, adding an 

5 indication of said verification to said acceptance note before providing said 

6 acceptance note to said first party participant. 
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: J - : A 1 , A ^hpd acpording to claim 1 0, wherein said step of adding an indication 

r 2 * .9C i 7-^^^? 1 *^'^^ ft< ^P t ^ lce note comprises the step of affixing a digital 

3 signature of ^d s^ondinopTp^ 

1 12. A computer readable storage medium for use with computer apparatus, 

2 said medium canying computer instructions which, when executed by said Computer 

3 apparatus: , , fT - p <t , r ,, v . y w , f -v. ^r.;v^:-ir 

4 ( a ) provide an electronic transaction document from ah issuer party 

5 participant to a first non- party participant, said document being non-repudiable by 

6 said issuer party participant and describing a transaction between said issuer party 

7 participant and at least pne recipient paity participant; 

8 0>) in response to yerification:by said non-party participant of at least 

9 one aspect of said electronic transaction document, add an indication of said 

10 verification to s^id electronic transaction document' and provide said electronic 

1 1 transaction document to said recipient, partytparticipant; and 1 ^ 

12 (<?) inresponseto acceptance.by said recipient party participant of said 

13 transaction as described in said electronic transaction document, provide to said 

14 issuer p^ty p^icipant an acceptance note, nbmrepudiable by said recipient party 
!5 . ; participant and evjdenci^g acceptance of said transaction by said recipient party 
16 participant. . ^ : , n:L : . vC , : . : r^.? ■ v;n?i- 



1 13. A medium according to claim 12, wherein said r electronic transaction 

2 document contains terms of said transaction. 



1 



*1 . „ A n^iupappo^ 

document contains at least one reference to terms of said transaction. 



3 15 - A medium according, to claim 12, wherein said electronic transaction 

4 document includes a digital signature of said issuer party participant. - 
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•;1 : . 16, ,_A medium according to claim 12, wherein said electronic transaction 
,2 ;J ' document includes^ digital signature of said nonparty participant ' i? 

1 17. A medium according: to claims, wherein said electronic transaction 

2 document includes an encrypted digest covering at least part of said electronic 
.3.,. r: transaction document..-; . ' ' •: ..• 

1 18. A medium according to claim 12, wherein said acceptance note includes 
2, , a.digital signature of saidrecipient party participant? 

1 19. A medium according to claim 12, wherein said acceptance note includes 

2 j. : .a digital signature of at least one non-party participant. 

1 20. A medium according to claim 12, wherein said acceptance note includes 
1, .....an encrypted digest covering at least part of said acceptance note. 



1 21. A computer readable storage medium for use with computer apparatus, 

2 . ^dmediumca^ 

..apparatus: r ... j -t.„" ■>■: ■ - : ■:.'.'> o:-=.t< • 4 ~ : .«*•.• ■>< ~>''- 

4 (a) provide an electronic transaction document to a firet non-party 

5 participant, said document being non-repudiable by an issuer party participant and 

6 describing-artransaction between ^d^'i^^'p^^arti^ant- and at least one 

7 recipient party participant;"' 'iv'^' v' r ; ir.^qr.zi V vuat ■■r: '^jr.-Ja- ' 

(b) in response to verification by said non-party participant of said 
^electronic transaction document/ receive s^d electronic transaction document and 

10 indication of said verification; ^ - , r 

1 1 (c) P rovide electronic transaction document and said indication of 

12 verification to said recipient party participant; and ' : 



8 

9- 
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13 t ( ., ; ( d ) bU^^^W se 10 acceptance by said recipient party participant of s^d 

14 transa^on^M^des^i?^ in said electronic .transaction document, - receive an 

15 acceptance note, non-repudiable by said recipient party participant and evidencing 

16 acceptance pf said transaction by said recipient^party participant. 

1 22. A medium according to claim 21, wherein said -electronic transaction 

2 document contains terms of said transaction. 



1 23. A medium according to claim 21, wherein said electronic transaction 

2 document contains at least one reference to terms of said transaction. 

1 24. A medium according to claim 21, wherein said electronic transaction 

2 document includes a digital signature of said issuer party participant. 

>> _ / ■■; ... * * ■ . - ■ - 

1 25. A medium according to ; claim 21, wherein said electronic transaction 

2 document includes a digital signature of said non-party participant. 

1 2 f; A medium according tp / plain? 21, twherein said electronic transaction 

2 document includes an encrypted digest covering at least part of said electronic 

3 transaction document , , r • 

1 v i v. ?; ^^^V^^^S^Q : c Nw 21*, wherein said acceptance note includes 

2 a digital signature of said recipient party partiripa&feq b o'^ : >? ^ v v 

1 28 A ^^M^;??^^" 1 ^:^ ^ therein said acceptance note includes 

2 a digital signature of at least one non-party participant. r ^ ; = , 

1 29. A medium according to claim 2 1, wherein said acceptance note includes 

2 an encrypted digest covering at least part of said acceptance note. 



BNSDOCIO <WO 0025245A1_I_> 



WO 00/25245 



PCT/US99/24570 



2 



10 
11 
12 



1 30. A computer readable storage medium foFu^el^' computer apparatus, 
said medium carrying ctom|W^iiu^-6tiom^cfe^^S^«i by said computer 

3 apparatus: 

4 ( a > ; receive ari electronic transaction document, said document being 
non-repudiable by an issuer party participant and describing a transaction between 
said issuer party participant and at least one recipient party participant, and an 

r indication of verification of said electronic transaction document by a first non-party 

8 participant; and' • ? r . .. , i: \ \ r : . ■ ; 

9 (b) response to acceptance by said recipient party participant of said 
fransaction as .•described in said electronic 'transition : 'document, provide an 
acceptance note, non-repudiable by said rebipient party participant and evidencing 
acceptance of said transaction by said recipient party participant. 



1 > 31, A medium according to claim 30, wherein said electronic transaction 

2 document contains terms of said transaction. 

1 : 32, . A medium according ?'to "claim 30, wherein said electronic transaction 

2 document contains at' least one reference to' terms of said transaction. 

1 33.-- ,q.,A medium acbordihg'to claim ; 30, : wlierem said electronic transaction 

2 , , document includes a digital signature of said issuer party participant. 

4, n34, Ij0 ob iA mediumr-accfafdihg "to claim' 3^ ^whe^ein' said electronic transaction 

A/ . s^PPumem :•• ' • ' 

1 35. A: medium- according to claim 30, wherein said" electronic transaction 

2 document includes an encrypted digest covering* at least part of said electronic 

3 •.- transaction document. -■■->- ' 
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36. A i»e^)ijm ; ^^ording to claim 30, wherein said acceptance note includes 
a digital .si^aj^^e, off ^recipient .party participant; ^ - - r\.'. \ • r- w ' 

37. A mediijrn according to claim 30, ; wherein said acceptance note includes 
a distal signature of a$ least one non-party participant:. 6 c, t ^ - • 

38. A medium ^cco^ding to claim 30, wherein said acceptance note includes 
an encrypted digest covering at least part of said acceptance note. , 

39 * , A computer : readable storage medium for use with computer apparatus, 
, said medium carrying computer instructions which, when executed by said computer 
apparatus: ^ ; 

(a) receive an electronic transaction document, said document being 
non-repudiable by an issiier party participant and describing^ transaction between 
said issuer party participant and at least one recipient party participant; 

(b) verify said electronic transaction document; and 

(c) , provide said rverifi^d electronic transaction document and an 
indication of said verification tp said issuer party participant. - - ; 

, r . r 40 * ; A : P?W? ut ?r r^^able. stqrage medium for use with computer apparatus, 
said medium carp^^^ said computer 

apparatus: 

,^ f .,.. .. ir / 7 ::^ ■ ^ ^9f^ document beirig 

non-repudiable, by an. i^u^party participant ^cfescrib^ 
said issuer party participant and at least one recipient party participant, said 
document containing an indication ,of verification by a non-party participant; 

(b) verify said received electronic transaction document; and 

(c) provide said verified electronic transaction document to said 
recipient party participant. 
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